The most recent options callback I reviewed did supply a URI and a CancellationToken as an argument

API usability point: should there be a single callback rather than individual ones?

Sounds like a good idea, a signature could be

In NatsAuthOpts:

   Func<Uri, CancellationToken, ValueTask<NatsAuthOpts>? Callback { get; init; } = null;

This would have to come with the caveat that a Callback could not return another NatsOptsAuth with a Callback

Or in NatsOpts:

   Func<Uri, CancellationToken, ValueTask<NatsAuthOpts>? AuthOptsCallback { get; init; } = null;

Could also be a slipper slope though, what other options could be updated between reconnects? And which ones could be updated after knowing the URI that will be connected to? Is it worth putting just the auth ones in now, or coming up with a broader approach to allow for updating all potential options

@mtmk at this point, do you have a feeling on how close we are to approval/merging?

And as a follow-up, how long can I expect until a new release is cut with these changes?

@garrett-sutton I'd like to allow a few days for others to have a chance to review and comment. All being well, I'd say we can merge and release early next week.

@mtmk sounds good. I'm looking to utilize the new feature in a new project at my org that we're trying to release soon. I just wanted to check in on where we are at. Thanks!